home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 860 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.4 KB  |  91 lines
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: To malloc (new) or not to malloc?  Clarification. Please ignore previous post.
  5. Date: Tue, 09 Jan 96 19:12:59 GMT
  6. Organization: none
  7. Message-ID: <821214779snz@genesis.demon.co.uk>
  8. References: <4ctvk3$ort@maverick.tad.eds.com> <4cua5t$dm@maverick.tad.eds.com>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <4cua5t$dm@maverick.tad.eds.com>
  15.            fignet05.darrins@eds.com "Darrin Smith" writes:
  16.  
  17. >I know that I should know the answer to this (I'm sure one of my past 
  18. >instructors made it clear while I was sleep.... I mean sitting in class), 
  19. >but I can't remember so...
  20. >
  21. >Why is it that you can do something like the following:
  22. >
  23. >        char *x;
  24.  
  25. This creates an object with type pointer to char and an identifier x which
  26. can be used to access it. If the declaration is ni a function the pointer is
  27. uninitialised so it is not legal to use its value. When you define a pointer
  28. only space for the pointer itself is allocated, never anything for the pointer
  29. to point to.
  30.  
  31. >        x="Some really long string with no particular meaning";
  32.  
  33. The string literal defines an object that is a static array of char, causes
  34. space to be allocated for that object at program startup (like any other
  35. static object). The array is initialised to the text of the string. The
  36. address of the first element of the static array is assigned to x which then
  37. has a well-defined value.
  38.  
  39. >and have no problems, but can't (safely) do something like this:
  40. >
  41. >        struct st1{char one[10];
  42. >                   char two[20];
  43. >                   char three[10];
  44. >                  };
  45. >
  46. >        st1 *sptr;      //or struct st1 *sptr in C instead of C++
  47.  
  48. Since you are posting to comp.lang.c, stick to C.
  49.  
  50. struct st1 *sptr; creates an object with type struct st2 * which is, again,
  51. an uninitilised pointer if this is in a function.
  52.  
  53. >        fread(sptr,sizeof(st1),1,infile);
  54.  
  55. fread requires you to pass a pointer to a buffer where it can store the
  56. data read. However you are passing the uninitialised value of sptr which
  57. is illegal.
  58.  
  59. >This caused a program I was trying to debug to crash.  When I allocated 
  60. >memory for sptr (I used sptr=new st1; but I suppose malloc would have done 
  61. >just as well) it worked fine.                   
  62.  
  63. malloc would have worked much better since new isn't defined in C!
  64.  
  65. By doing this you have set sptr to point to a valid buffer. You can therefore
  66. pass that pointer value to fread.
  67.  
  68. >What is going on here?  Why isn't memory set aside for st1 *sptr just as 
  69. >it is for char *x?
  70.  
  71. In both cases memory is allocated for the pointer itself. In neither case
  72. is any other memory allocated - the pointers don't point to anything
  73. until you assign a valid pointer value to them. The 2 pointr are behaving in
  74. exactly the same way, the only difference being the method used to create
  75. an object for them to point to.
  76.  
  77. > Before I did the new (or malloc) it seemed as though 
  78. >my program was getting written over!
  79. >
  80. >Why?
  81.  
  82. The uninitialised pointer could have held any value (or no meaningful value) -
  83. it could have pointed right into your program hence causing fread to overwrite
  84. it.
  85.  
  86. -- 
  87. -----------------------------------------
  88. Lawrence Kirby | fred@genesis.demon.co.uk
  89. Wilts, England | 70734.126@compuserve.com
  90. -----------------------------------------
  91.